Date: Sun,  1 Aug 93 21:13:21 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #226
To: packet-radio


Packet-Radio Digest         Sun,  1 Aug 93       Volume 93 : Issue  226

Today's Topics:
                      BayComm and BayPac Modems 
                           FBB Server Help
                Guide to the Personal Radio Newsgroups
                              HF Packet
         INTERNET & FIDONET links to Amateur Packet (2 msgs)
    Is  rec.radio.amateur.packet  about to die? Read on. (3 msgs)
                        TCP/IP via radio link?
                          X1J and the DR200

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 30 Jul 1993 07:45:56 +0000
From: news!demon!imcldn.demon.co.uk!mike@uunet.uu.net
Subject: BayComm and BayPac Modems 
To: packet-radio@ucsd.edu

In article <9307271926.AA05597@golden-grahams> taalebi@ai.mit.EDU writes:

>Hello there.
>   I wonder if anyone has used any of these modems:
>           BayCom 
>   for software-based TNC's?
>
>   Your comments on their performance will be appreciated.
>   I would specially like to know about their KISS mode capabilitis and 
>   baud rate limits.

I use a Baycom Modem, with the TFPCX driver, and the F6FBB BBS Software as
a PMS, runns 20 channels in theory, I have had it up to 5 simultaneous user
connections, and 3 forwarding sessions though...
-- 
Mike Simkins  G7OBS @ G7OBS.GB7DAA.#33.GBR.EU (Packet)
              g7obs @ imcldn.demon.co.uk      (Internet)

------------------------------

Date: Fri, 30 Jul 1993 20:45:39 +0000
From: news!demon!g1xgp.demon.co.uk!g1xgp@uunet.uu.net
Subject: FBB Server Help
To: packet-radio@ucsd.edu

Hi folks,
I am running FBB and paKet. Is there a Server available for FBB where a 
YAPP download can be posted to a Private File Area, which can be viewed 
by the SysOp only, and then posted to FBB/YAPP for general uploading. 
This facility is available with paKet.

73's Steve G1XGP

   ------------------------------------------------------------------
   + Steve Blinkhorn    + G1XGP @ GB7DUG.#32.GBR.EU (Amateur Radio) +
   + AMPRnet            + g1xgp@g1xgp.ampr.org      [44.131.16.147] +
   + Essex Packet Group + g1xgp@g1xgp.demon.co.uk   (Internet)      +
   ------------------------------------------------------------------

------------------------------

Date: Sun, 1 Aug 1993 16:41:06 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!wupost!crcnis1.unl.edu!news.unomaha.edu!news@network.ucsd.edu
Subject: Guide to the Personal Radio Newsgroups
To: packet-radio@ucsd.edu

Posted-By: auto-faq 2.4
Archive-name: radio/personal-intro
Revision: 1.4 06/30/93 12:04:14
Changes: new rec.radio.amateur.* newsgroups, cs.utexas.edu gateway

(Note:  The following is reprinted with the permission of the author.
Due to the recent reorganization, it is also on a temporarily-
accelerated posting schedule as follows:

July      weekly
August    bi-weekly
September back to monthly)

This message describes the rec.radio.amateur.*, rec.radio.cb, rec.radio.info,
and rec.radio.swap newsgroups. It is intended to serve as a guide for the new
reader on what to find where. Questions and comments may be directed to the
author, Jay Maynard, K5ZC, by Internet electronic mail at
jmaynard@oac.hsc.uth.tmc.edu. This message was last changed on 30 June 1993 to
add the groups created during the latest reorganization vote and the
description of the cs.utexas.edu gateway.

History
=======

Way back when, before there was a Usenet, the Internet hosted a mailing list
for hams, called (appropriately enough) INFO-HAMS. Ham radio discussions
were held on the mailing list, and sent to the mailboxes of those who had
signed up for it. When the Usenet software was created, and net news as we
now know it was developed, a newsgroup was created for hams: net.ham-radio.
The mailing list and the newsgroup were gatewayed together, eventually.

As the net grew, and as packet radio came into vogue, packet discussion began
to dominate other topics in the group and on the list. This resulted in the
logical solution: a group was created to hold the packet discussion, and
another corresponding mailing list was created as well: net.ham-radio.packet
and PACKET-RADIO, respectively.

These two groups served for several years, and went through Usenet's Great
Renaming essentially unchanged, moving from net.ham-radio[.packet] to
rec.ham-radio[.packet]. Readership and volume grew with the rest of the
network.

The INFO-HAMS mailing list was originally run from a US Army computer at
White Sands Missile Range, SIMTEL20. There were few problems with this
arrangement, but one was that the system was not supposed to be used for
commercial purposes. Since one of hams' favorite pastimes is swapping
gear, it was natural for hams to post messages about equipment for sale
to INFO-HAMS/rec.ham-radio. This ran afoul of SIMTEL20's no-commercial-use
restriction, and after some argument, a group was created specifically
for messages like that: rec.ham-radio.swap. This group wasn't gatewayed to
a mailing list, thus avoiding problems.

While all this was happening, other folks wanted to discuss other aspects
of the world of radio than the personal communications services. Those
folks created the rec.radio.shortwave and rec.radio.noncomm newsgroups,
and established the precedent of the rec.radio.* hierarchy, which in turn
reflected Usenet's overall trend toward a hierarchical name structure.

The debate between proponents of a no-code ham radio license and its opponents
grew fierce and voluminous in late 1989 and 1990. Eventually, both sides grew
weary of the debate, and those who had not been involved even more so. A
proposal for a newsgroup dedicated to licensing issues failed. A later
proposal was made for a group that would cover the many recurring legal issues
discussions. During discussion of the latter proposal, it became clear that it
would be desirable to fit the ham radio groups under the rec.radio.*
hierarchy. A full-blown reorganization was passed by Usenet voters in January
1991, leading to the overall structure we now use. 

After the reorganization, more and more regular information postings began to
appear, and were spread out across the various groups in rec.radio.*. Taking
the successful example of the news.answers group, where informational postings
from across the net are sent, the group rec.radio.info was created in
December, 1992, with Mark Salyzyn, VE6MGS, initially serving as moderator.

In January, 1993, many users started complaining about the volume in
rec.radio.amateur.misc. This led to a discussion about a second
reorganization, which sparked the creation of a mailing list by Ian Kluft,
KD6EUI. This list, which was eventually joined by many of the most prolific
posters to the ham radio groups, came up with a proposal to add 11 groups to
the rec.radio.amateur hierarchy in April 1993. The subsequent vote, held in
May and early June, approved the creation of five groups:
rec.radio.amateur.digital.misc (to replace .packet), .equipment, .homebrew,
.antenna, and .space.

The Current Groups
==================

I can hear you asking, "OK, so this is all neat history, but what does it
have to do with me now?" The answer is that the history of each group has
a direct bearing on what the group is used for, and what's considered
appropriate where.

The easy one is rec.radio.amateur.misc. It is what rec.ham-radio was renamed
to during the reorganization. Any message that's not more appropriate in one
of the other groups belongs here, from contesting to DX to ragchewing on VHF
to information on becoming a ham.

The group rec.radio.amateur.digital.misc is for discussions related to
(surprise!) digital amateur radio. This doesn't have to be the common
two-meter AX.25 variety of packet radio, either; some of the most
knowledgeable folks in radio digital communications can be found here, and
anything in the general area is welcome. The name was changed to emphasize
this, and to encourage discussion not only of other text-based digital modes,
such as AMTOR, RTTY, and Clover, but things like digital voice and video as
well. The former group, rec.radio.amateur.packet, has not been removed as of
this writing, but it is obsolete, and you should use .digital.misc instead.
The group has the .misc as part of the name to allow further specialization if
the users wish it, such as .digital.tcp-ip. 

The swap group is now rec.radio.swap. This recognizes a fact that became
evident shortly after the original group was formed: Hams don't just swap ham
radio gear, and other folks besides hams swap ham equipment. If you have radio
equipment, or test gear, or computer stuff that hams would be interested in,
here's the place. Equipment wanted postings belong here too. Discussions about
the equipment generally don't; if you wish to discuss a particular posting
with the buyer, email is a much better way to do it, and the other groups,
especially .equipment and .homebrew, are the place for public discussions.
There is now a regular posting with information on how to go about buying and
selling items in rec.radio.swap; please refer to it before you post there. 

The first reorganization added two groups to the list, one of which is
rec.radio.amateur.policy. This group was created as a place for all the
discussions that seem to drag on interminably about the many rules,
regulations, legalities, and policies that surround amateur radio, both
existing and proposed. The neverending no-code debate goes here, as does
the New Jersey scanner law, the legality of ordering a pizza on the
autopatch, what a bunch of rotten no-goodniks the local frequency
coordinating body is, and so on.

The other added group is rec.radio.cb. This is the place for all discussion
about the Citizens' Band radio service. Such discussions have been very
inflammatory in rec.ham-radio in the past; please do not cross-post to both
rec.radio.cb and rec.radio.amateur.* unless the topic is genuinely of interest
to both hams and CBers - and very few topics are.

The rec.radio.info group is just what its name implies: it's the place where
informational messages from across rec.radio.* may be found, regardless of
where else they're posted. As of this writing, information posted to the group
includes Cary Oler's daily solar progagation bulletins, ARRL bulletins, the
Frequently Asked Questions files for the various groups, and radio
modification instructions. This group is moderated, so you cannot post to it
directly; if you try, even if your message is crossposted to one of the other
groups, your message will be mailed to the moderator, who is currently Mark
Salyzyn, VE6MGS. The email address for submissions to the group is
rec-radio-info@ve6mgs.ampr.ab.ca. Inquires and other administrivia should be
directed to rec-radio-request@ve6mgs.ampr.ab.ca. For more information about
rec.radio.info, consult the introduction and posting guidelines that are
regularly posted to that newsgroup.

The groups rec.radio.amateur.antenna, .equipment, .homebrew, and .space are
for more specialized areas of ham radio: discussions about antennas,
commercially-made equipment, homebrewing, and amateur radio space operations.
The .equipment group is not the place for buying or selling equipment; that's
what rec.radio.swap is for. Similarly, the .space group is specifically about
amateur radio in space, such as the OSCAR program and SAREX, the Shuttle
Amateur Radio EXperiment; other groups cover other aspects of satellites and
space. Homebrewing isn't about making your own alcoholic beverages at home
(that's rec.crafts.brewing), but rather construction of radio and electronic
equipment by the amateur experimenter. 

The rec.radio.amateur.misc, .packet, and .policy groups, and the
rec.radio.info group, are available by Internet electronic mail in digest
format; send a mail message containing "help" on a line by itself to
listserv@ucsd.edu for instructions on how to use the mail server. The
rec.radio.swap group is not available for reading by electronic mail. At this
writing, the most recently added groups are also not available for reading by
electronic mail, although that may change.

All of the groups can be posted to by electronic mail, though, by using a
gateway at the University of Texas at Austin. To post a message this way,
change the name of the group you wish to post to by replacing all of the '.'s
with '-'s - for example, rec.radio.swap becomes rec-radio-swap - and send to
that name@cs.utexas.edu (rec-radio-swap@cs.utexas.edu, for example). You may
crosspost by including multiple addresses as Cc: entries (but see below). This
gateway's continued availability is at the pleasure of the admins at
UT-Austin, and is subject to going away at any time - and especially if
forgeries and other net.abuses become a problem. You have been warned. 

A Few Words on Crossposting
===========================

Please do not crosspost messages to two or more groups unless there is genuine
interest in both groups in the topic being discussed, and when you do, please
include a header line of the form "Followup-To: group.name" in your article's
headers (before the first blank line). This will cause followups to your
article to go to the group listed in the Followup-To: line. If you wish
to have replies to go to you by email, rather than be posted, use the word
"poster" instead of the name of a group. Such a line appears in the headers
of this article.

One of the few examples of productive cross-posting is with the rec.radio.info
newsgroup. To provide a filtered presentation of information articles, while
still maintaining visibility in their home newsgroups, the moderator strongly
encourages cross-posting. All information articles should be submitted to the
rec.radio.info moderator so that he may simultaneously cross-post your
information to the appropriate newsgroups. Most newsreaders will only present
the article once, and network bandwidth is conserved since only one article is
propagated. If you make regular informational postings, and have made
arrangements with the moderator to post directly to the group, please
cross-post as appropriate.

--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@oac.hsc.uth.tmc.edu      | adequately be explained by stupidity.
      "If my car ran OS/2, it'd be there by now" -- bumper sticker
                 GCS d++ p+ c++ l+ m+/- s/++ g++ w++ t+ r

--
73, Paul W. Schleck, KD3FU

pschleck@unomaha.edu

Celebrating 60 years of the Univ. of Maryland ARA - W3EAX (1933-1993)

------------------------------

Date: Fri, 30 Jul 1993 20:05:42 GMT
From: swrinde!gatech!howland.reston.ans.net!agate!linus!linus.mitre.org!mwvm.mitre.org!M16616@network.ucsd.edu
Subject: HF Packet
To: packet-radio@ucsd.edu

A few words on the use and reliability of HF HAM Packet would be helpful.
THANKS.  :-)   :-)
 

------------------------------

Date: Fri, 30 Jul 1993 20:08:27 GMT
From: swrinde!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!agate!linus!linus.mitre.org!mwvm.mitre.org!M16616@network.ucsd.edu
Subject: INTERNET & FIDONET links to Amateur Packet
To: packet-radio@ucsd.edu

Various people have said that it is "no problem" to link Amateur Radio packet t
o FIDONET and INTERNET. I would be interested in hearing from someone with
hands on experience who does this routinely. Thanks.  :-)  :-)
 

------------------------------

Date: 1 Aug 93 06:19:16 GMT
From: pacbell.com!amdahl!amdahl!ikluft@ames.arpa
Subject: INTERNET & FIDONET links to Amateur Packet
To: packet-radio@ucsd.edu

[Followups directed to rec.radio.amateur.digital.misc]

M16616@mwvm.mitre.org writes:
>Various people have said that it is "no problem" to link Amateur Radio packet
>to FIDONET and INTERNET. I would be interested in hearing from someone with
>hands on experience who does this routinely.

Whatever you arrange, don't gate a Fidonet group into rec.radio.amateur.packet
because it is being replaced by rec.radio.amateur.digital.misc.  The packet
newsgroup will be removed on Sept 21st.

So, if you want to arrange a gateway to Fidonet, make sure you arrange a
"digital amateur radio" discussion over there, not just packet radio.
-- 
Ian Kluft  KD6EUI PP-ASEL         Amdahl Corporation, Open Systems Development
ikluft@uts.amdahl.com                                          Santa Clara, CA
[disclaimer: any opinions expressed are mine only... not those of my employer]

------------------------------

Date: Thu, 29 Jul 93 20:59:58 EST
From: swrinde!cs.utexas.edu!uwm.edu!spool.mu.edu!torn!nott!cunews!revcan!balsam!pinetree!gordon@network.ucsd.edu
Subject: Is  rec.radio.amateur.packet  about to die? Read on.
To: packet-radio@ucsd.edu

da884@cleveland.Freenet.Edu (David Toste) writes:

> The following USENET groups are being removed on the dates indicated.
> To help ease the transition, you might wish to mark them as "no local
> posting allowed" at your site, with the C News/INN flag "n".
>  
> GROUP                           DATE  SUPERSEDED BY
> NOTE: rec.radio.amateur.packet        0921  rec.radio.amateur.digital.misc
> 
> Looks to me that the last day for this group is on Sept 21th~!!!
> 
> What gives?
> 

As it clearly (I think) says, rec.radio.amateur.packet is going to be 
rmgroup'd on or near September 21.  There was a CFV for a re-org of the 
rec.radio.amateur hierarchy and rec.radio.amateur.digital.misc was 
passed, meaning that rec.radio.amateur.packet is redundant because it 
falls under the definition of the new r.r.a.d.m group.

Relax.... you'll still have a group to talk about packet in.

  --G

--
  Internet:  gordon@pinetree.org              |     Guillotine operators
  UUCP:  ...!pinetree!gordon                  |      get severance pay.
  Packet:  VE3XGD@VE3JF                       |           * VE3XGD *
  Gordon's Pinetree - Ottawa, Ontario, Canada - +1 613 526 0702 - v32bis/v42bis

------------------------------

Date: 1 Aug 1993 21:54:03 GMT
From: nothing.ucsd.edu!brian@network.ucsd.edu
Subject: Is  rec.radio.amateur.packet  about to die? Read on.
To: packet-radio@ucsd.edu

Seems I overlooked an alternative that someone was kind enough to point
out in mail to me: we could also create an 'alt' group for packet radio
and gateway the mailing list there.

This would work, of course, but it wouldn't have a good a propagation
as a more mainstream 'rec' group would have.
	- Brian

------------------------------

Date: Sun, 01 Aug 93 17:43:56 -0400
From: psinntp!wlnntp.psi.com!usenet@uunet.uu.net
Subject: Is rec.radio.amateur.packet about to die? Read on.
To: packet-radio@ucsd.edu

Has rec.radio.amateur.digital.misc been created yet?  The newserver I 
use hasn't created it yet, if it has.

Thanks, Seth

------------------------------

Date: Sat, 31 Jul 1993 20:37:34 GMT
From: usc!sol.ctr.columbia.edu!destroyer!vela.acs.oakland.edu!w8hd!NewsWatcher!user@network.ucsd.edu
Subject: TCP/IP via radio link?
To: packet-radio@ucsd.edu

I need some advise...
 
What I would like to find is an extension for the Macintosh OS, like
VersaTerm's SLIP tool, that could be used with MacTCP to provide TCP/IP
connections via some sort of radio link.  
 
I don't think I need a TNC  and an AX.25 type device/software. I don't want
to send anything different over the radio link than I would over a regular
modem link when using SLIP or PPP.
 
Any ideas?

Jim Hebert, K8SS

jimh@w8hd.org

------------------------------

Date: Sat, 31 Jul 1993 09:55:18 +0000
From: news!demon!llondel.demon.co.uk!dave@uunet.uu.net
Subject: X1J and the DR200
To: packet-radio@ucsd.edu

In article <22s7qt$alj@gopher.cs.uofs.edu> bill@gopher.cs.uofs.edu (Bill Gunshannon) writes:
> 
> Has anyone with access to the source looked at putting a version
> of X1? on the DR200??  It seems that the dual port box would
> make a great IP gateway between a local LAN and a backbone.
> 
> bill   KB3YV
> 
I dropped a line to the author on this and got the following back:

>Can you post a reply for me saying that I am quite happy to give the
>source to anyone interested in doing such a version - and that I will
>also offer assistance in doing it.
>
>
>Please don't post the code yet - it needs changes.

I have tracked down a local DR200 occupying shelf space so I will have a go
at it when the source arrives. 

For those who have asked for the beta-test version, note his last comment!

Dave

*****************************************************************************
* G4WRW @ GB7WRW.#41.GBR.EU AX25     *    You think *you* have problems?    *
* dave@llondel.demon.co.uk  Internet *     What do you do if you *are*      *
* g4wrw@g4wrw.ampr.org      Amprnet  *      a manically depressed robot??   *
*****************************************************************************

------------------------------

Date: Sat, 31 Jul 1993 18:41:58 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!gatech!emory!kd4nc!ke4zv!gary@network.ucsd.edu
To: packet-radio@ucsd.edu

References <25223@acorn.co.uk>, <1993Jul29.180807.13354@ke4zv.uucp>, <25256@acorn.co.uk>
Reply-To : gary@ke4zv.UUCP (Gary Coffman)
Subject : Re: Packet can't work

In article <25256@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes:
>In article <1993Jul29.180807.13354@ke4zv.uucp> gary@ke4zv.UUCP (Gary Coffman) writes:
>>Channel pathology can still be a problem if stations aren't using
>>p-persistance backoff. Stations can still butt heads again and 
>>again if they use a fixed Dwait and both happen to start during the
>>window of vulnerability. And they *will* always start during the
>>window if the channel is busy. Both will try to transmit as soon
>>as data carrier from a previous channel user drops. So p-persistance
>>is essential to making a busy channel work, whether it's duplex or
>>simplex.
>
>Right, but p-persistence only helps by deliberately introducing some
>dead-time, just as polling systems introduce their own overhead.

If the p-persist parameters are adjusted properly, there is practically
no dead time. The channel fills to just slightly below capacity and stays
there. That's been my experience with several stations doing file
transfers on the channel. The channel stays constantly busy until
another station joins with a collision. The channel then slows for
a moment, p-persist only backs off with a packet failure, then 
readjusts so that channel time is again fully occupied.

>In both cases, the inefficiency introduced is related to the number
>of users on the channel (since the p-persist coefficient is supposed
>to be related to the expected load) but it's possibly more convenient
>to have the central hub adjust the loading than the user's nodes.
>Of course, this doesn't preclude the user's nodes being adjusted by
>some other, centralised authority based at the repeater.

There are several problems with central authority control. The first
is the problem of stations joining and leaving the group. The second
is a matter of single point failure. Inactive stations can be "aged"
out fairly gracefully, but joining the system is more difficult for
the transient station. There has to be a dead slot available where
any station can call to join. That waste is there every round of the
round robin poll. Alternatively, out of band signaling can be used,
but that's wasteful of spectrum. 

Single point failure is more confusing. If the master station dies
in a polling system, then the channel dies as every station waits 
it's turn to transmit, but none receives a permission packet. The
permission packets also represent considerable overhead. In token 
passing schemes, the token can be regenerated by any station after 
a timeout, but it's possible to have multiple tokens circulating 
if care is not taken. With CSMA, these problems don't exist. However,
if a repeater is in use, it also represents a single point failure
node that requires user intervention (one of each pair of stations
going upside down) to work around. That's the primary advantage of
simplex operation, either no action is required when a station
dies, or only a reroute operation needs to be done.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: 2 Aug 93 03:19:08 GMT
From: pacbell.com!amdahl!amdahl!ikluft@ames.arpa
To: packet-radio@ucsd.edu

References <23bfs4INNd1h@network.ucsd.edu>, <pschleck.744051384@cwis>, <23h927INNj4b@network.ucsd.edu>
Subject : Re: Is rec.radio.amateur.packet about to die? Read on.

brian@nothing.ucsd.edu (Brian Kantor) writes:
>Yup, at three years, you're a newbie.  You've only been around Usenet
>since the farcical "voting" process got popular.  You seem confused
>about the power and effect the votes have.

Oh, I see...  }:-)

Since you called us all newbies in your first message on this subject, I'm
going to have fun deflating your flame... piece by piece.

I have been using UseNet since 1985 (8 years.)  I am not a newbie.  Many
others to whom you aim your statements have been on the Net at least as long.
You've only heard of me and many of the others for three years because that's
how long you've been complaining about the FAQs we post.  That's about how
long most FAQs have been around.

OK, one point of yours has been shot down.

>Please do try to remember:  Usenet is *NOT* a democracy.  The votes
>are ADVISORY to the administrators of the news systems; there is NO
>compulsion for any administrator to follow the result of any such
>result when he believes that to be wrong or against his best interests. [...]

Hmmm... You seem to imply none of us knew how UseNet admins fit into the
picture.  Allow me to establish some credentials in this category since it
seems that you assume people have no experience when you haven't heard of it.

I've been pretty closely observing how news administration is done since it
arrived at the univerity I attended.  I've been involved in news admin work
as an aside from my software development duties ever since starting at Amdahl
over 3 years ago.  I was the leader of the team that set up the amdahl.com
firewall and news/mail/uucp hub machine on an Amdahl 7300 Unix mainframe.
So you're not the only one on the block who can see what news looks like on
a big system.

Besides, it doesn't take as long as you seem to think for anyone to figure
out that the news admin sets the policy on local newsgroup creation and
retention.  But don't get the idea that there's any single way to do it
either - many don't have time to follow news.groups.  They'll do whatever
they please within the limits of their time, disk space, and management.

We know that.  Now you know we know it.  Another point shot down.

>You admit that the "voting guidelines" are only that, and that they
>weren't equal to the survey that you needed to make, yet you somehow
>feel you needed to follow them and to follow their inappropriate result.

What wasn't equal and how's that significant.  Surveys and discussion were
conducted for a month before the 30-day discussion.  So that's more time
than most newsgroups get.

Also, is the result "inappropriate" just because you don't like it?  Only
at your site.  Not necessarily on the rest of UseNet, as you imply.

Yet another point shot down.

>And you were told that the tcp people (as surveyed in the tcp mailing
>list) didn't a newsgroups, yet you went ahead with the proposal, and
>express surprise at the negative result!

All inputs were considered, including but not limited to yours.  No one
will apologize if that disappoints you.  The transcripts of that discussion
and the news.groups discussion are *still* available by ftp if you want to
see what people thought were the pros and cons on that point.

The proposal evolved as more inputs were made.  The digital radio groups
received strong support from the packet radio community, expect for your
single opposing view.  The rest of the opposing views were withdrawn whenever
anyone mentioned that the packet community appeared to favor it.

Based on the available information, there is little doubt that it was correct
to put it up for a vote and accept the outcome.  That was done.  You should
accept the part that passed, rec.radio.amateur.digital.misc, because there
is no other opinion poll which can supersede the vote.

>Remember that good intentions often pave the path into hell.

Oh my... what could you possibly mean by that?!  }:-)  (The horns on that
smiley seem particularly appropriate to poke fun at that one!  heh heh...)

>I've asked the people on the packet-radio mailing list what they want
>me to do.  If there is some consensus and it seems reasonable, that's what
>I'll do.  I am more interested in the fate of the mailing lists than
>of the Usenet newsgroups; the mailing lists have always been of more
>benefit, interest, and importance to me.

Ah ha!  Now we get to the bottom of the matter...  (!!!)

Yes, Brian.  You have made everyone repeatedly aware that the UCSD mail lists
are the most, if not only, important things in your view of UseNet.

You have opposed everything that is different from how UseNet was 5 or more
years ago.  Open your eyes - the 90's have arrived (years ago.)  Things are
changing.  Are you going to adapt or just keep complaining?

Some things just have to change because of the increasing traffic on
UseNet and the Internet.  For example, you have vocally opposed the FAQs,
claiming they are a waste of bandwidth.  Yet many more people have said they
appreciate them than all of your complaints combined.  Maybe you didn't
notice the trend a few years ago to make this kind of information available
on UseNet where people are already looking for it.  The trend continues
because a lot of people think it works.

Honestly, it looks like you're always trying to be a thorn in the side of
anyone who's trying to participate in the volunteer postings on the
rec.radio.amateur newsgroups.  I would not be disappointed if you decided to
*disconnect* all your mail lists from the newsgroups.  You're behind the
times and you appear unwilling to try to catch up.

Frankly, I'm tired of hearing your repetitive whining, Brian.  I've tried to
work with you.  I've tried to be polite...  I've been patient.  Those clearly
won't work.  You need not expect those any more until you show some
flexibility.

It can't work any less than the previous approach did.  It's soooooooooooo
frustrating to try to work with you.

>No need to worry about
>Usenet - it will survive anything even well-meaning people can do to it.

I know you're aiming that at Paul, me, and others.  Are you including
yourself in that?  If so, I agree completely.  If not (as your tone implies),
I suggest you remember that there's more to the world, and UseNet, than any
single person's view of it.
-- 
Ian Kluft  KD6EUI PP-ASEL         Amdahl Corporation, Open Systems Development
ikluft@uts.amdahl.com                                          Santa Clara, CA
[disclaimer: any opinions expressed are mine only... not those of my employer]
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